Aspects of the present invention relate generally to integrated circuit designs, and in particular to techniques for simulation and test of such designs.
Hardware designers, for example integrated circuit (IC) designers, do not always design every component of a new hardware device. While designers may design one or more components of a particular device, they often employ component designs (also known as intellectual property, or IP) from one or more third-party IP providers. Using components from third-party IP providers can facilitate the design by avoiding the need for the designer to design every aspect of the device's functionality.
Hardware designers may employ a hardware based verification platform to perform certain operations on a design. Hardware verification platforms can enable testing of the various components of the design which facilitates design analysis and debugging. Multiple aspects of the hardware design typically may be tested. For example, a hardware design may undergo architectural simulation and analysis and debugging where the functionality of each of the components being implemented in the design is tested, for example, with transaction level modeling (TLM) or bus functional modeling. The hardware design may additionally undergo circuit simulation and analysis where the signals between components are tested, for example using register transition level (RTL) analysis. Other steps may include system simulation, for example to model the components of a system together, and system and software emulation, for example to model execution of software elements executing on a modeled system. Once a design is completed, one or more components of the device may be tested and verified. Such testing may require a device specific driver to verify that the inputs and outputs over a communication medium conform to a standard or predefined protocol.
A simulation platform conventionally models the hardware components at various levels of abstraction. Processor models implementing Instruction Set Simulators (ISS) in combination with hardware simulators can be used to simulate cross-compiled embedded software, for example, an operating system (OS). A collection of hardware models running such embedded software is known as a Virtual Platform (VP). When simulating a driver for design IP with a conventional VP, due to timing, programming language, and interface limitations of the driver, the modeled processors and operating systems are not practical for simulating execution of the driver. However, if the driver is executed in the workstation or other execution platform, hardware components modeled on the VP will be cut off from communication with the workstation processor and, consequently, with the driver. Timing differences may also exist between the driver running on the workstation processor or other execution platform with reference to a standard clock (wall time) and the design IP objects running on the simulator with reference to the executed simulation (simulator or design time). Due to such different and independent time domains and execution processors, cross-domain communications can cause dead-loop or hanging during the simulation, either in the driver code execution (on the workstation), or in the design IP component execution (on the simulator). Additionally, the simulation of some design IP components in this configuration may cause the simulation to hang where the simulated objects encounter a loop in the simulation. Thus additional modules and interfaces, as well as entirely new drivers, are often developed to simulate a driver and interface associated with the design IP of a device under test. However, driver development is error-prone and time consuming.
Therefore, there is a need in the art for more efficient systems and methods to simulate design IP interface drivers.